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Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 
Abstract 
This memo defines Transport Layer Security (TLS) extensions and 
associated semantics that allow clients and servers to negotiate the 
use of OpenPGP certificates for a TLS session, and specifies how to 
transport OpenPGP certificates via TLS. It also defines the registry 
for non-X.509 certificate types. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6091. 
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Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The IETF has two sets of 
set for the use of X.509 certificates [RFC5280], 
certificates [RFC4880]. At the time of this writing, 
standards are defined to 


use X.509 certificates. 


February 2011 


standards for public key certificates: one 

and one for OpenPGP 
TLS [RFC5246] 

This document 


specifies a way to negotiate the use of OpenPGP certificates fora 


TLS session, 


TLS. 


current TLS specification, 


and specifies how to transport OpenPGP certificates via 
The proposed extensions are backward-compatible with the 
so that existing client and server 


implementations that make use of X.509 certificates are not affected. 


These extensions are not backward-compatible with [RFC5081], and the 


major differences are summarized in Appendix A. 


Although the OpenPGP 


CertificateType value is being reused by this memo with the same 

number as that specified in [RFC5081] but with different semantics, 
we believe that this causes no interoperability issues because the 
latter was not widely deployed. 


2. Terminology 


The term "OpenPGP key" 
specification [RFC4880]. 


is used in this document as in the OpenPGP 
We use the term "OpenPGP certificate" to 


refer to OpenPGP keys that are enabled for authentication. 


This document uses the same notation and terminology used in the TLS 
Protocol specification [RFC5246]. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Changes to the Handshake Message Contents 


This section describes the changes to the TLS handshake message 
contents when OpenPGP certificates are to be used for authentication. 


3.1. Client Hello 


In order to indicate the support of multiple certificate types, 
clients MUST include an extension of type "cert_type" to the extended 
client hello message. The "cert_type" TLS extension is assigned the 
value of 9 from the TLS ExtensionType registry. This value is used 
as the extension number for the extensions in both the client hello 
message and the server hello message. The hello extension mechanism 
is described in [RFC5246]. 


This extension carries a list of supported certificate types the 
client can use, sorted by client preference. This extension MUST be 
omitted if the client only supports X.509 certificates. The 
"extension_data" field of this extension contains a 
CertificateTypeExtension structure. Note that the 
CertificateTypeExtension structure is being used both by the client 
and the server, even though the structure is only specified once in 
this document. Reusing a single specification for both client and 
server is common in other specifications, such as the TLS protocol 
itself [RFC5246]. 


enum { client, server } ClientOrServerExtension; 
enum { X.509(0), OpenPGP (1), (255) } CertificateType; 


struct { 
select (ClientOrServerExtension) { 
case client: 
CertificateType certificate_types<1..2%8-1>; 
case server: 
CertificateType certificate_type; 
} 


} CertificateTypeExtension; 


No new cipher suites are required to use OpenPGP certificates. All 
existing cipher suites that support a key exchange method compatible 
with the key in the certificate can be used in combination with 
OpenPGP certificates. 
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3.2. Server Hello 


If the server receives a client hello that contains the "cert_type" 
extension and chooses a cipher suite that requires a certificate, 
then two outcomes are possible. The server MUST either select a 
certificate type from the certificate_types field in the extended 
client hello or terminate the session with a fatal alert of type 
"unsupported_certificate". 


The certificate type selected by the server is encoded ina 
CertificateTypeExtension structure, which is included in the extended 
server hello message using an extension of type "cert_type". Servers 
that only support X.509 certificates MAY omit including the 
"cert_type" extension in the extended server hello. 


3.3. Server Certificate 


The contents of the certificate message sent from server to client 
and vice versa are determined by the negotiated certificate type and 
the selected cipher suite’s key exchange algorithm. 


If the OpenPGP certificate type is negotiated, then it is required to 
present an OpenPGP certificate in the certificate message. The 
certificate must contain a public key that matches the selected key 
exchange algorithm, as shown below. 


Key Exchange Algorithm OpenPGP Certificate Type 

RSA RSA public key that can be used for 
encryption. 

DHE_DSS DSA public key that can be used for 
authentication. 

DHE_RSA RSA public key that can be used for 
authentication. 


An OpenPGP certificate appearing in the certificate message is sent 
using the binary OpenPGP format. The certificate MUST contain all 
the elements required by Section 11.1 of [RFC4880]. 


OpenPGP certificates to be transferred are placed in the Certificate 
structure and tagged with the OpenPGPCertDescriptorType 
"subkey_cert". Since those certificates might contain several 
subkeys, the subkey ID to be used for this session is explicitly 
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specified in the OpenPGPKeyID field. The key ID must be specified 
even if the certificate has only a primary key. The peer, upon 
receiving this type, has to either use the specified subkey or 
terminate the session with a fatal alert of 
"unsupported_certificate". 


The option is also available to send an OpenPGP fingerprint, instead 
of sending the entire certificate, by using the 
"subkey_cert_fingerprint" tag. This tag uses the 
OpenPGPSubKeyFingerprint structure and requires the primary key 
fingerprint to be specified, as well as the subkey ID to be used for 
this session. The peer shall respond with a 
"certificate_unobtainable" fatal alert if the certificate with the 
given fingerprint cannot be found. The "certificate_unobtainable" 
fatal alert is defined in Section 5 of [RFC6066]. 


Implementations of this protocol MUST ensure that the sizes of key 
IDs and fingerprints in the OpenPGPSubKeyCert and 
OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover, 
it is RECOMMENDED that the keys to be used with this protocol have 
the authentication flag (0x20) set. 


The process of fingerprint generation is described in Section 12.2 of 
[RFC4880]. 


The enumerated types "cert_fingerprint" and "cert" of 
OpenPGPCertDescriptorType that were defined in [RFC5081] are not used 
and are marked as obsolete by this document. The "empty_cert" type 
has replaced "cert" and is a backward-compatible way to specify an 
empty certificate; "cert_fingerprint" MUST NOT be used with this 
updated specification, and hence that old alternative has been 
removed from the Certificate struct description. 
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enum { 
empty_cert (1), 
subkey_cert (2), 
subkey_cert_fingerprint (3), 
(255) 

} OpenPGPCertDescriptorType; 


uint24 OpenPGPEmptyCert = 0; 


struct { 
opaque OpenPGPKeyIDK<8..255>; 
opaque OpenPGPCert<0..2%24-1>; 
} OpenPGPSubKeyCert; 


struct { 

opaque OpenPGPKeyID<8..255>; 

opaque OpenPGPCertFingerprint<20..255>; 
} OpenPGPSubKeyFingerprint; 


struct { 

OpenPGPCertDescriptorType descriptorType; 

select (descriptorType) { 
case empty_cert: OpenPGPEmptyCert; 
case subkey_cert: OpenPGPSubKeyCert; 
case subkey_cert_fingerprint: 

OpenPGPSubKeyCertFingerprint; 
} 


} Certificate; 
3.4. Certificate Request 


The semantics of this message remain the same as in the TLS 
specification. However, if this message is sent, and the negotiated 
certificate type is OpenPGP, the "certificate_authorities" list MUST 
be empty. 


3.5. Client Certificate 


This message is only sent in response to the certificate request 
message. The client certificate message is sent using the same 
formatting as the server certificate message, and it is also required 
to present a certificate that matches the negotiated certificate 
type. If OpenPGP certificates have been selected and no certificate 
is available from the client, then a certificate structure of type 
"empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 
The server SHOULD respond with a "handshake_failure" fatal alert if 
client authentication is required. 
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3.6. Other Handshake Messages 


All the other handshake messages are identical to the TLS 
specification. 


4. Security Considerations 


All security considerations discussed in [RFC5246], [RFC6066], and 
[RFC4880] apply to this document. Considerations about the use of 
the web of trust or identity and certificate verification procedures 
are outside the scope of this document. These are considered issues 
to be handled by the application layer protocols. 


The protocol for certificate type negotiation is identical in 
operation to cipher suite negotiation as described in the TLS 
specification [RFC5246], with the addition of default values when the 
extension is omitted. Since those omissions have a unique meaning 
and the same protection is applied to the values as with cipher 
suites, it is believed that the security properties of this 
negotiation are the same as with cipher suite negotiation. 


When using OpenPGP fingerprints instead of the full certificates, the 
discussion in Section 5 of [RFC6066] for "Client Certificate URLs" 
applies, especially when external servers are used to retrieve keys. 
However, a major difference is that although the 
"client_certificate_url" extension allows identifying certificates 
without including the certificate hashes, this is not possible in the 
protocol proposed here. In this protocol, the certificates, when not 
sent, are always identified by their fingerprint, which serves as a 
cryptographic hash of the certificate (see Section 12.2 of 
[RFC4880]). 


The information that is available to participating parties and 
eavesdroppers (when confidentiality is not available through a 
previous handshake) is the number and the types of certificates they 
hold, plus the contents of the certificates. 


5. IANA Considerations 
This document uses a registry and the "cert_type" extension 


originally defined in [RFC5081]. Existing IANA references have been 
updated to point to this document. 
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In addition, the "TLS Certificate Types" registry established by 
[RFC5081] has been updated in the following ways: 

1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 


2. Values from 2 through 223 decimal inclusive are assigned via "RFC 
Required" [RFC5226]. 


3. Values from 224 decimal through 255 decimal inclusive are 
reserved for Private Use [RFC5226]. 
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Appendix A. Changes from RFC 5081 


This document incorporates a major change in the "Server Certificate" 
and "Client Certificate" TLS messages that will make implementations 
following this protocol incompatible with those following [RFC5081]. 
This change requires the subkey IDs used for TLS authentication to be 
marked explicitly in the handshake procedure. This was decided in 
order to place no limitation on the OpenPGP certificates’ contents 
that can be used with this protocol. 


[RFC5081] required that an OpenPGP key or subkey be marked with the 
authentication flag; thus, authentication would have failed if this 
flag was not set or if this flag was set in more than one subkey. 
The protocol in this memo has no such limitation. 
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